X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C92FD7.E3680C40@onstor-exch02.onstor.net>; Thu, 16 Oct 2008 14:41:03 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C92FD7.E3680C40"
Content-class: urn:content-classes:message
Subject: RE: Functional Spec for Restarting Aborted Mirror Sessions
Date: Thu, 16 Oct 2008 14:41:03 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E0C0D8792@onstor-exch02.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E0C0D8754@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Functional Spec for Restarting Aborted Mirror Sessions
Thread-Index: Ackvwc2p16X2XnVpSBWREx63PQrjQQADPGaAAABkD3AAAc2vMA==
References: <BB375AF679D4A34E9CA8DFA650E2B04E0C0D86BA@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E0C0D8733@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E0C0D8754@onstor-exch02.onstor.net>
From: "Deepak Veliath" <deepak.veliath@onstor.com>
To: "Jonathan Goldick" <jonathan.goldick@onstor.com>,
	"dl-Design Review" <dl-designreview@onstor.com>
Cc: "dl-Kegg" <dl-Kegg@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C92FD7.E3680C40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Another problem is that storing just the block number will not do.  The
snapshots that were being delta'ed will also have to be known.  Unless
its being suggested that the snapshot details are stored at one place
and the block-number in the target.

veliath

> _____________________________________________=20
> From: 	Deepak Veliath =20
> Sent:	Thursday, October 16, 2008 2:05 PM
> To:	Jonathan Goldick; dl-Design Review
> Cc:	dl-Kegg
> Subject:	RE: Functional Spec for Restarting Aborted Mirror
> Sessions
>=20
> Hello Jonathan,
> 1.	Section 5, as you make clear, the key to restarting is to know
> what the target has on disk, basically a checkpoint marker.  Since we
> send blocks in order can we just periodically write out the last block
> number know to have hit disk?  A super-block field would be easy.
> While an implementation note, this would avoid changing the cluster DB
> and that is relevant here.  When all the blocks have been received we
> can just set the number to the last block number in the file system so
> it handles a lot of the cases you have mentioned.
>=20
> We issue I/Os to read the blocks on the source in order.  But there
> seems to be no guarantee the I/Os finish and return in that order.  We
> send out blocks to the target as soon as they have been read.  On the
> target again the I/O is issued as they come in over the RMC connection
> but there seems to be no guarantee of ordering.  I realize our current
> IO scheduler might guarantee some sort of ordering, but this could
> change in the future.  The mirroring sub-system shouldn't expect it
> works a certain way unless the IO scheduler exports a mechanism to
> guarantee this ordering.
>    =20
> 2.	Section 6, I'm not sure that the restart command adds a lot,
> avoiding the creation of a new snapshot is the only clear addition
> over mirror start and that doesn't seem worth creating a new command
> verb.
>=20
> Since creating a new snapshot consumes some amount of space (and will
> mean space can be allocated as the FS is modified), I felt a "restart"
> only command would allow a previously aborted mirror to run through to
> completion without potentially consuming space in the FS.
> =20
> 3.	Section 6, mirror start MIRRORNAME [skiprestart] To date we have
> not used whole words for command options in the shell, but instead use
> things like -a, -b, etc.  Other than testing, why would a customer
> ever want to skip a restart?  While a large transfer can happen at any
> point, the real problem here is baseline transfers so if the target is
> garbage in some way we can just start over by detecting that, rather
> than having the administrator try to figure it out.  This also reduces
> the test cases and the need to change the GUI or the CLI.=20
>=20
> I see a lot of "force" options in the existing mirroring commands --
> they were the basis for this choice.  I'll change it to "-s".  As to
> the need for such an option, I felt a mechanism to bypass the whole
> restart logic and being able to fall-back on to the traditional logic
> might be desired by an administrator.  The baseline transfer has
> nothing to do with this option and can be completed successfully with
> or without this option.
>=20
> Thank you,
> veliath
> =20
>=20
> =20
>=20
> =20
>=20
> ________________________________
>=20
> From: Deepak Veliath=20
> Sent: Thursday, October 16, 2008 12:03 PM
> To: dl-Design Review
> Subject: Functional Spec for Restarting Aborted Mirror Sessions
>=20
> =20
>=20
> \\mightydog\software\Kegg\Functional
> Specs\RestartAbortedMirrorSessionsFuncSpec.doc
> <file:///\\mightydog\software\Kegg\Functional%20Specs\RestartAbortedMi
> rrorSessionsFuncSpec.doc>=20
>=20

------_=_NextPart_001_01C92FD7.E3680C40
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: Functional Spec for Restarting Aborted Mirror =
Sessions</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><SPAN LANG=3D"en-us"><FONT COLOR=3D"#800000" SIZE=3D2 =
FACE=3D"Verdana">Another problem is that storing just the block number =
will not do.&nbsp; The snapshots that were being delta'ed will also have =
to be known.&nbsp; Unless its being suggested that the snapshot details =
are stored at one place and the block-number in the =
target.</FONT></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT COLOR=3D"#800000" SIZE=3D2 =
FACE=3D"Verdana">veliath</FONT></SPAN>
</P>
<UL>
<P><SPAN LANG=3D"en-us"><FONT SIZE=3D1 =
FACE=3D"Tahoma">_____________________________________________ =
</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D1 FACE=3D"Tahoma">From: =
&nbsp;</FONT></B> <FONT SIZE=3D1 FACE=3D"Tahoma">Deepak Veliath&nbsp; =
</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D1 =
FACE=3D"Tahoma">Sent:&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Tahoma">Thursday, October 16, 2008 2:05 PM</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D1 =
FACE=3D"Tahoma">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Tahoma">Jonathan Goldick; dl-Design Review</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D1 =
FACE=3D"Tahoma">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Tahoma">dl-Kegg</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D1 =
FACE=3D"Tahoma">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Tahoma">RE: Functional Spec for Restarting =
Aborted Mirror Sessions</FONT></SPAN>
</P>

<P><SPAN LANG=3D"en-us"><FONT COLOR=3D"#800000" SIZE=3D2 =
FACE=3D"Verdana">Hello Jonathan,</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Section 5, as you make =
clear, the key to restarting is to know what the target has on disk, =
basically a checkpoint marker.&nbsp; Since we send blocks in order can =
we just periodically write out the last block number know to have hit =
disk?&nbsp; A super-block field would be easy.&nbsp; While an =
implementation note, this would avoid changing the cluster DB and that =
is relevant here.&nbsp; When all the blocks have been received we can =
just set the number to the last block number in the file system so it =
handles a lot of the cases you have mentioned.</FONT></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT COLOR=3D"#800000" SIZE=3D2 =
FACE=3D"Verdana">We issue I/Os to read the blocks on the source in =
order.&nbsp; But there seems to be no guarantee the I/Os finish and =
return in that order.&nbsp; We send out blocks to the target as soon as =
they have been read.&nbsp; On the target again the I/O is issued as they =
come in over the RMC connection but there seems to be no guarantee of =
ordering.&nbsp; I realize our current IO scheduler might guarantee some =
sort of ordering, but this could change in the future.&nbsp; The =
mirroring sub-system shouldn't expect it works a certain way unless the =
IO scheduler exports a mechanism to guarantee this =
ordering.</FONT></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">&nbsp;&nbsp;&nbsp; </FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Section 6, I&#8217;m =
not sure that the restart command adds a lot, avoiding the creation of a =
new snapshot is the only clear addition over mirror start and that =
doesn&#8217;t seem worth creating a new command verb.</FONT></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT COLOR=3D"#800000" SIZE=3D2 =
FACE=3D"Verdana">Since creating a new snapshot consumes some amount of =
space (and will mean space can be allocated as the FS is modified), I =
felt a &quot;restart&quot; only command would allow a previously aborted =
mirror to run through to completion without potentially consuming space =
in the FS.</FONT></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">&nbsp;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Section 6, mirror =
start MIRRORNAME [skiprestart] To date we have not used whole words for =
command options in the shell, but instead use things like &#8211;a, -b, =
etc.&nbsp; Other than testing, why would a customer ever want to skip a =
restart?&nbsp; While a large transfer can happen at any point, the real =
problem here is baseline transfers so if the target is garbage in some =
way we can just start over by detecting that, rather than having the =
administrator try to figure it out.&nbsp; This also reduces the test =
cases and the need to change the GUI or the CLI. </FONT></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT COLOR=3D"#800000" SIZE=3D2 =
FACE=3D"Verdana">I see a lot of &quot;force&quot; options in the =
existing mirroring commands -- they were the basis for this =
choice.&nbsp; I'll change it to &quot;-s&quot;.&nbsp; As to the need for =
such an option, I felt a mechanism to bypass the whole restart logic and =
being able to fall-back on to the traditional logic might be desired by =
an administrator.&nbsp; The baseline transfer has nothing to do with =
this option and can be completed successfully with or without this =
option.</FONT></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT COLOR=3D"#800000" SIZE=3D2 =
FACE=3D"Verdana">Thank you,</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#800000" SIZE=3D2 =
FACE=3D"Verdana">veliath</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">&nbsp;</FONT></SPAN>
</P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">&nbsp;</FONT></SPAN>
</P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">&nbsp;</FONT></SPAN>
</P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">________________________________</FONT></SPAN>
</P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Verdana">From: Deepak =
Veliath </FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Verdana">Sent: Thursday, =
October 16, 2008 12:03 PM</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Verdana">To: dl-Design =
Review</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Verdana">Subject: =
Functional Spec for Restarting Aborted Mirror Sessions</FONT></SPAN>
</P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">&nbsp;</FONT></SPAN>
</P>

<P><SPAN LANG=3D"en-us"></SPAN><A =
HREF=3D"file://\\mightydog\software\Kegg\Functional"><SPAN =
LANG=3D"en-us"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Verdana">\\mightydog\software\Kegg\Functional</FONT></U></SPAN></=
A><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Verdana"> =
Specs\RestartAbortedMirrorSessionsFuncSpec.doc &lt;</FONT></SPAN><A =
HREF=3D"file:///\\mightydog\software\Kegg\Functional%20Specs\RestartAbort=
edMirrorSessionsFuncSpec.doc"><SPAN LANG=3D"en-us"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Verdana">file:///\\mightydog\software\Kegg\Functional%20Specs\Res=
tartAbortedMirrorSessionsFuncSpec.doc</FONT></U></SPAN></A><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Verdana">&gt; </FONT></SPAN></P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C92FD7.E3680C40--
